The multiplayer megapacket Twinsen Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy. Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening. The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped. The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.

New Fluid system 2 (Dominik) Hi Factorians, Here is Dominik, with an update on the fluids. This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features. In FFF-260 I wrote about how it all started, why we are doing it and what the plan is. There was a huge response from you all and I want to thank everyone for their contributions. Let me apologise to redditors, as at the beginning I started responding on the forums and when I realized there is reddit too, there were too many comments for me to handle. The forum users produced many ideas on how the system could work. About third of them was a fluid teleportation, many where known but many were entirely new and interesting. What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience. I won’t go through them here, you can find them on the forums or reddit. There were two proposals on the forum though that were so good that they made it into the game - from quinor and TheYeast. Both of these proposals were very similar and kinda similar to the previous game logic. What it shares is that the mechanic still uses fluid physics simulation and volume in a pipe as a base for the movement calculation. As a result, not much changes on the first glance. What they add though is an emphasis on the fluid network update being independent on the current state (i.e. updating one pipe only depends on state from the last tick) and is therefore independent on evaluation order, which was one of the big pains of the old model that led to sometimes ridiculous junction behavior. Difference between these two was rather small - quinor’s version allowed perfect throughput with 3 passes over the fluidboxes (fluidbox is the thing managing fluids for entities, so I will talk about them), while Yeast’s one was 2 pass with ¼ throughput. What was outstanding though is that TheYeast, a physicist, supported the model with a nice theoretical background and what’s more, he made an amazing JS simulator to test and compare various modification of the model. Because that extra pass in quinor’s version was too high a price for the perfect throughput, I went with TheYeast’s two pass one. Since the old algorithm only used a single pass run by entities for the update, I first needed to overhaul the whole system to allow accommodating the new one. Going from one pass to two passes necessarily means higher complexity, so we made a big effort to optimize everything we could to make sure we will still end up faster than 0.16. Kovarex wrote about it in FFF-271.

Team production changes Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love. So after 4 years of accruing wisdom, I started making some general improvements.

A week in the office This week is another week of typical bug fixing, so I thought we would make a one-time change of style and do a day-by-day account of what exactly that means for us.

Roadmap update (kovarex) A lot of people have been asking recently, when can they expect a new release and when is the game going to be finished. The original plan was to finish everything, and release the final version of Factorio ideally before the end of 2018. This was the plan at the beginning of the year. We worked in our usual way of "it is done when it is done" for quite some time, but then it started taking a little bit too long, and we weren't even sure what is a realistic timeframe to finish it in. To help this issue, we tried to become a little more organized in the past few weeks. We went through our list of all the development tasks, and tried to finalize it. We removed all the things that we decided to cut, and added all the missing things that we need to do before the game is finished. Then we tried to make some kind of time estimate for each task, to get a general idea of when everything will be finished. We started to be more conscious of who is working on what, and how much time each task is taking, to know how accurate the estimates are. The result was, that if it all goes well, we could be done in 6-9 months. This is probably not something you wanted to hear. After a few rounds of discussions, we decided split the releases of 0.17 and 0.18 in the following way: 0.17 plan It will contain all the things we have done up to this point, mainly: New render backend, which helps performance and solves a lot of issues (FFF-251) The graphical updates: walls, gates, turrets, belts, biters, spawners, electric poles (FFF-268, FFF-228, FFF-253) The GUI reskin (FFF-243) New map editor (FFF-252) Resource generation overhaul (FFF-258) Robot construction tools (FFF-255) Rich text (FFF-237, FFF-267) And more... It will also include some things we know we can finish soon enough, mainly: Redoing some of the most important GUIs (Action bar, character screen, main game GUI, train GUI, play GUI, tooltips) Fluid optimisations And several smaller things, which depends on how it goes We will release this during January 2019, we will announce it more precisely in advance. 0.18 plan It will become the final 1.0 version once it is stable. It will contain mainly: New tutorial New campaign Final mini tutorials Revision of rest of the GUI All remaining high res graphics graphics and final polish We obviously don't know exactly when is it going to be ready, but we hope it to be sooner than 9 months from now.

New pathfinding algorithm Oxyd Last week we mentioned the change to make biters not collide with each other, but that wasn’t the only biter-related update we released this past week. Somewhat coincidentally, this week’s updates have included something I’d been working on for a few weeks before – an upgrade to the enemy pathfinding system.

Hello, I have an irresistible urge to tell you a little story. I'm sure you come here for stories, don't you?

Hello! There are certain areas in Factorio that we haven't really had the courage to change for a long time. One of those areas has been the rail system...

Hello, we would like to talk about the remote view changes coming in the 2.0 base game update. This is one of the foundations to be able to talk about the space platform and planets later, so lets get into it!

The boring phase of bug-fixing is still going, slowly but surely. Stable should be released next week, but with some people on vacation (Ben, Jitka, kovarex, Klonan, Sanqui) and with the release of WoW Classic, it might get slowed down a bit. (By the way, some of us will be playing on Pyrewood Village, Alliance, so if you want to have the chance of meeting Twinsen, kovarex or dominik while leveling, you can join that server). So since there's not much happening, this week we decided to explore some unpopular or controversial opinions about the game from within the team. In Wube we don't have a very strict management structure, everyone is free to have ideas and opinions about almost all aspects of the game. This means that with almost every change we argue and discuss a lot before making a final decision. Sometimes we argue about everything, from the smallest GUI change, to how a major feature should work. This is probably not a bad thing since this means changes are usually well thought out and unpopular ideas or changes don't make it to the game very often. Some people feel quite strongly about their opinions or sometimes the team is very divided on what should we do. Today we'll share some of those opinions and controversies. Keep in mind that these are simply opinions and none of them will actually make it into the game, we are simply sharing them to have an interesting discussion.